These are quick first looks and trend and threats


Read More >>
Written by the security and AV professionals from team K7, meant for the general audience
Read More >>
These are usually articles that go into internals of a virus or deal with security issues
Read More >>
Senior managers speak on areas of interest to them, inside and outside the industry
Read More >>

Archive for the ‘Banking Malware’ Category

New Trick up the Sleeve: Trickbot Delivered Via Fake Banking Forms

Friday, June 8th, 2018

Trickbot, a banking Trojan family that has been around for some time now, aims at stealing banking credentials from infected victims. This blog post talks about a new variant of this Trojan that (ab)uses PowerShell, MS-Word macros and Office Equation Editor vulnerabilities as its infection vectors.

The document comes via email disguised as a BACS (Bacs Payment Schemes Limited, formerly known as Bankers’ Automated Clearing Services) request form as depicted in Figure 1.

Figure 1: Fake BACS request form that looks identical to the original form

The sender’s email id, “noreply@lloydsbcnk.com”, is crafted, a common enough social engineering technique to deceive an unsuspecting user into opening the attachment, which then requires the user to enable macros, claiming that this is necessary to auto-fill the form. Figure 2 depicts the flow of execution on opening the malicious DOC attachment and enabling the macros.

Figure 2: Execution flow

Macros contained in the Word document are depicted in Figure 3.

Figure 3: Macros

Once enabled, the macros triggered creates the cmd and PowerShell processes as depicted in Figure 2 to execute the script for downloading the Trickbot binary. Here’s the actual PowerShell script that gets executed:

Figure 4: Actual script (courtesy of app.any.run)

Figure 5: Reformatted form of script for better readability

PowerShell is now one of the most widely abused Windows components by malware authors since it is available by default on modern Windows and interacts easily with the .NET framework. The Trickbot script uses the .NET API “DownloadFile” from a common .NET class (System.Net.Webclient) for downloading the malware’s preliminary binary component. Some thoughts on why this specific API was chosen:

  • The download happens in the background. There is no download progress indicator, i.e. the user is completely unaware of what’s happening
  • The thread cannot be interrupted until the current download is complete or fails.

The script also has a failsafe mechanism by way of a try/catch block which provides alternative download links to the binary component which were specifically created for the purpose of serving this malware:

  • hxxp[:]//interbanx[.]co[.]id/lopagores[.]png
  • hxxp[:]//chimachinenow[.]com/lopagores[.]png

These two domains were also found to host other malicious files as depicted in Figure 6.

Figure 6: Other malicious files hosted (courtesy of VirusTotal)

Once lopagores.png (which is actually a Portable Executable, i.e. PE) is downloaded successfully, the script executes it using the Start-Process command from a hard-coded path that keeps changing from sample to sample (temporary location as shown in Figure 5).

Behavioral analysis of the downloaded binary file

The binary component then copies itself to a sub-folder under the user’s %APPDATA% area along with another file named “client_id”, which contains the system details like the machine name and OS version, as well as an arbitrarily generated string to identify the bot and the campaign to which it belongs as depicted in Figure 7.

Figure 7: Sub-folder under %APPDATA% (NB: sample has been renamed to its SHA256 hash value)

An aptly-named folder “Modules” is also created along with the above files that acts as a placeholder for:

  • Any modules that get downloaded or pushed from the C&C (Command and Control) server
  • Files that are injected into various browsers to scrape user credentials

Persistence is taken care of by a scheduled task with multiple triggers created with the name “MsNetValidator” to masquerade as a legitimate task, a simple but effective way to hide from the average user.

Figure 8: Scheduled task for persistence

Registry modifications are also made (as shown in Figure 9) to exclude its folder from Windows Defender scans.

Figure 9: Registry entry for exclusion from Windows Defender scan

Before contacting any C&C server for downloading additional modules, the malware first retrieves the host IP by simply querying one or more of the following domains until a response is received.

www[.]ipify[.]org      icanhazip[.]com        myextrnalip[.]com
wtfismyip[.]com        ip[.]anysrc[.]net      api[.]ipify[.]org
ipecho[.]net           ipinfo[.]io            checkip[.]amazonaws[.]com

It injects into the legitimate svchost process to modify the scheduled task for the next trigger as depicted in Figure 2.

Inside the code of the downloaded binary file

The main binary component, a Visual C executable, is designed to decrypt the malicious code only at runtime.

Decryption

This piece of malware performs multiple layers of decryption before the final bad act. For those who are interested here’s a slightly more detailed explanation. The 1st level (bog standard) decryption of some bytes followed by a call to the decrypted bytes is seen in Figure 10.

Figure 10: 1st level of decryption

The 2nd level (evasive action) involves the decrypted code allocating more memory into which further encrypted content is copied and decrypted, and another call is made to that decrypted content as seen in Figure 11.

Figure 11: The 2nd level of decryption

In the 3rd level (definitely bad) this decrypted code allocates even more memory, and more encrypted code is loaded into it and decrypted, which happens to be the “meaningful” malware code.

Figure 12: 3rd level of decryption to “meaningful” malware code

Our analysis also shows that it scans the memory for traces of monitoring tools and/or malware analysis-related processes. The list of processes that it scans for is as follows:

pstorec.dll
vmcheck.dll
dbghelp.dll
wpespy.dll
api_log.dll
sbiedll.dll
SxIn.dll
dir_watch.dll
Sf2.dll
cmdvrt32.dll
snxhk.dll

These names are stored in encrypted form without any special character or entropy so as to avoid easy detection based on strings or entropy. If none of the aforementioned process are found active, the malware goes on to copy itself to user’s %APPDATA% folder (as depicted earlier in Figure 7) and launches itself as a new process. This process, after verifying it is in fact running from under the user’s %APPDATA% folder, goes on to decrypt another Visual C binary (as depicted in Figure 13), which does not touch the disk at all, i.e. it is decrypted, read and memory mapped whilst in memory itself.

Figure 13: Final decryption (Trickbot payload)

Before passing on the execution flow to the decrypted file in memory, the malware checks if it is being debugged by calling the function ZwQueyInformationProcess with the parameter ProcessInformationClass set to 0, which retrieves the pointer to the PEB (Process Environment Block) structure, which is in turn read to conclude if the process is being debugged or not as depicted in Figure in 14.

Figure 14: Check if being debugged

This decrypted binary in memory is the actual payload of Trickbot which is responsible for tasks like:

  • Querying the local IP
  • Ensuring persistence (via registry and scheduled tasks)
  • Creating the “Modules” folder
  • Decrypting a configuration file from its resource (as depicted in Figures 15 & 16) using functions from NCrypt.dll or BCrypt.dll
  • Contacting C&C server

Figure 15: Encrypted config file content stored in resources

Figure 16: Retrieving functions from NCrypt.dll or BCrypt.dll

The decrypted resource blob (as depicted in Figure 17) is saved as Config.conf under the user’s %APPDATA% folder.

Figure 17: Content of Config.conf file

<ver> tag indicates the Trickbot version which is 1000166, <gtag>  indicates the campaign ID and <srv> has the list of C&C IPs and ports for downloading additional modules. The C&C pushes custom or specific modules for specific targets which are responsible for code injection, mailcollector, sqlfinder, screenlock, etc. on successful validation of request received from Trickbot payload.

Same malware, different vulnerability

We also saw instances of this malware being served via a crafted MS-Word document which tries to exploit the Office Equation Editor vulnerabilities, i.e. CVE-2017-11882 and CVE-2017-8570 This crafted document, in the guise of a “Payment advice” form from HSBC bank, gets delivered from a typo-squatted domain “noreply@hsbc-paymentadvice.co.uk” or “noreply@hsbcpaymentadvice.co.uk” in an attempt to make the email look legitimate. The crafted document probably uses ThreadKit because it drops task.bat under the %Temp% folder and executes it using cmd.exe (typical ThreadKit behaviour) which will be followed by a PowerShell process (as depicted earlier in Figure 2). Figure 18 shows the actual PowerShell script and its reformatted form used to download the executable.

Figure 18: PowerShell Script (courtesy of app.any.run)

From Figure 18, it is evident that both infection vectors use the same domains to download the malware. The file downloaded by the second method is a Microsoft Visual Basic 5.0 compiled binary (the reader may recall that the first method downloaded a Visual C binary), but it drops a similar Trickbot payload during runtime though. Our analysis indicates that this banking Trojan constantly seeks new infection vectors and is still very active. The malware authors are still implementing new functionalities and modules.

Indicators of Compromise (IoCs)

File details

DOC file:

FA9762828CF25F0182CC5A6781E708DA   (fake Lloyds Bank DOC)  Trojan ( 0001140e1 )
5FE7EF0E15A4E9468018E0A76457D159   (fake HSBC bank DOC)	   Trojan ( 0001140e1 )

PowerShell script:

7B177E32052DCF80830A087C9157A598   (Script from Lloyds Bank DOC)  Trojan ( 0001140e1 )
A5E7AF38D0CC548071B1B93731CE2B62   (Script from HSBC bank DOC)	  Trojan ( 0001140e1 )

Executables:

C4634916686AD740E1D17F23721152E2  (EXE from fake Lloyds DOC)  Trojan ( 0052cf591 )
1E9BC9805114D86B411F5DDEF01C67D0  (EXE from fake HSBC DOC)    EmailWorm ( 003c363a1 )

K7 products also have dynamic detection for the Trickbot variants.

URLs List

hxxp[:]//interbanx[.]co[.]id   (malicious domain blocked by K7SafeSurf)
hxxp[:]//chimachinenow[.]com   (malicious domain blocked by K7SafeSurf)

Lokesh J
Threat Researcher, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader: http://blog.k7computing.com/feed

EXtOrtion Banking bOT – EXOBOT!

Friday, February 23rd, 2018

This blog intends to describe a few new techniques used by the latest versions of Exobot, an Android Banking Trojan. These new techniques have been introduced to complicate the process of reversing engineering and to evade detection by security products.

It is only natural that, with huge increase in the number of Android smartphones users and availability of mobile banking services, cybercriminals have focused on malware targeting banking apps and other apps that enable financial transactions to embezzle funds from victims’ accounts. Devices infected with such malware would subject the users to be victims of the following (non-exhaustive):

• Financial loss
• Loss of Personally Identifiable Information (PII)
• Loss of privacy

Typically, banking Trojans await instructions from remote Command-and-Control (C&C) servers, thus allowing the attacker(s) to potentially turn compromised devices into involuntary but blissful bots. Also, the bad guys tend to keep changing their distribution mechanisms and infection routines (without compromising the severity of intended damage) to evade detection by security products. Unsurprisingly, Android banking Trojans are no exceptions in these aspects.

Exobot is an Android banking Trojan like any other. As described in our previous blog it steals users’ banking credentials from infected devices to enable the attacker(s) to siphon off their funds.

But here’s how this piece of malware is different. Our analysis revealed some interesting implementation techniques employed in recent versions for detection evasion which we have depicted in the following picture:

In case you find the above picture to be not-so-self-explanatory, please read on for a more detailed explanation on the differences between the older (Exobot V1) and newer (Exobot V2) versions.

Technique 1:

Exobot V1’s AndroidManifest.xml file contains all broadcast receivers, permissions and other privileges registered to perform malicious activities. All its eggs in one basket.

Exobot V1 Permissions

Exobot V2, on the other hand, has its requirements spread out. Basic installation and device admin registration are requested in the primary component (earlier available on the Google Play Store, but thankfully not anymore), which then downloads a secondary bot component, the requirements of which are handled within its own AndroidManifest.xml.

Exobot V2 Permissions split between parent and dropped components

The secondary component, downloaded from the URL shown in the following picture, then tries to connect to different C&C servers to receive commands from remote attacker(s).

It is noteworthy that the primary component retries downloading the secondary component multiple times (up to 5 times in the variant we analyzed) at regular intervals in case of failures when connecting to the URL specified. If all attempts to connect to this URL fail, it then tries to connect to other C&C servers from a predefined list.
Technique 2:

Exobot V1 is very trusting. It starts its malicious activities without checking the configuration of the device on which it is running. Exobot V2 is more cautious. It deploys multiple verification mechanisms before behaving badly. Here are the most interesting of such checks it carries out before proceeding with its infection routine.

Checks if device is connected to debugger



where,
n.df + n.fv + n.eF – android.os.Debug
n.es + n.eG + n.fu – isDebuggerConnected

Verifies if device configuration does not match any of the below criteria

  • Is the malware running within a test environment, say an emulator? Does any one of the below default values of an emulator match with the extracted values from the device?
    • Build.MODEL is “google_sdk or Emulator or Android SDK built for x86″
    • Build.MANUFACTURER is “Genymotion” (“GenyMotion” is an emulator frequently  used for QA or tests)
    • Build.PRODUCT is “google_sdk or sdk or sdk_x86 or vbox86p”
    • DeviceId is like “000000000000000” or “012345678912345” or “004999010640000″
    • VERSION.RELEASE is “0”
  • Is the compromised device connected to a test network?
    • SIM operator is “android” or “emergency calls only” or “fake carrier”
If any of the above match, execution stops



Checks and sets the malicious app as the default SMSPackage



The Android OS has the flexibility to programmatically set a user app as the default app to handle SMS. Exobot V2 leverages this option to be the first to access incoming SMS, as well as to suppress the messages from other installed apps by aborting the “SMS_Received” broadcast.
Verifies if “MAIN_VERSION_REQUIRED” is less than a specific threshold value to ensure that the bot can run on the device, i.e. on that particular version of Android OS


Where n.aT maps to “Bot is not able to run that command” and n.aU maps to “Command execution system error”.

Technique 3:

Exobot V2 also mimics an anti-reversing technique from its Windows-based counterparts. All the strings in the malware’s code are obfuscated, though with a very simple logic of inserting junk characters in between. For example:

a(“start”) may be converted to something like a(“s**EJz**t**EJz**a**EJz**r**EJz**t**EJz**”)

In the above example, “**EJz**” are the junk characters.

Our lab researchers regularly track Android banking Trojans, especially for their behavioral and technical differences, in order to ensure we are able to block the malware at the earliest with new and updated detection methodologies. K7 Mobile Security users are protected against both the older and newer versions of this malware.

Exobot V1 (example sample hash: b4064f4bca2ac0780a5e557b551a3755) is detected as “Spyware ( 004fdfc01 )”.

Exobot V2: The primary component (example sample hash: 6924d51242386e3c20c84f017f1838b9) is detected as “Trojan-Downloader ( 004f07451 )”, and the secondary component (example sample hash: f66e30974435e5ef092aeb7c9e5cad7a) is detected as “Trojan ( 005243d11 )”.

As always K7 Threat Control Lab makes the following recommendations:
  • Use a highly-reputable mobile security product such as K7 Mobile Security to block any infection
  • Regularly update the mobile OS and security applications installed to be free of mobile malware
  • Refrain from installing apps recommended by strangers
  • Review the reputation of any app before downloading and installing it
  • Choose to download and install apps only from the official Google Play store, as immediate & regular security actions are taken in emergency situations
  • Do not enable “Download from Unknown Sources”

V.Dhanalakshmi
Senior Threat Researcher

If you wish to subscribe to our blog, please add the URL provided below to your blog reader: http://blog.k7computing.com/feed

How Safe is Android Mobile Banking?

Monday, January 8th, 2018
There has been some recent media interest in one variant of Android Banking Trojans, also known as ‘Bankbots’. Bankbots have been around for a pretty long time now, i.e. nothing new, and the variant of unusual interest was already blocked by K7 Mobile Security as Trojan ( 0051c57a1 ).

As the name suggests Banking Trojans help hackers to steal money from a user’s account without his/her knowledge. This particular Android Banking Trojan scans the list of running apps for package names related to popular banking apps from all over the world in order to intercept incoming bank-related SMS messages, suppressing them from the user and redirecting them to a remote hacker. It can accept commands from a C&C server.

This Banking Trojan disguises itself as a Flash Player app hosted on third party markets. In order to carry out its malicious behavior silently the Trojan requests the user to provide device administrator privileges.

For this Trojan to start its malicious behavior it registers many receivers for various actions on the device as listed below:

  • android.provider.Telephony.SMS_DELIVER
  • android.provider.Telephony.WAP_PUSH_DELIVER
  • android.intent.action.BOOT_COMPLETED
  • android.intent.action.QUICKBOOT_POWERON
  • android.intent.action.USER_PRESENT
  • android.intent.action.PACKAGE_ADDED
  • android.intent.action.PACKAGE_REMOVED
  • android.provider.Telephony.SMS_RECEIVED
  • android.intent.action.SCREEN_ON
  • android.intent.action.EXTERNAL_APPLICATIONS_AVAILABLE
  • android.intent.category.HOME
  • android.net.conn.CONNECTIVITY_CHANGE
  • android.net.wifi.WIFI_STATE_CHANGED
  • android.intent.action.DREAMING_STOPPED
  • android.app.action.DEVICE_ADMIN_DISABLED
  • android.app.action.ACTION_DEVICE_ADMIN_DISABLE_REQUESTED
  • android.app.action.DEVICE_ADMIN_ENABLED

One of the receivers “yqyJqWdtdf.UOaOrquyRDgLFgGueha.resiverboot” that is registered for the SMS_Received broadcast is shown below:

The Trojan also requests for the following permissions:

  • android.permission.READ_CONTACTS
  • android.permission.INTERNET
  • android.permission.WAKE_LOCK
  • android.permission.GET_TASKS
  • android.permission.READ_PHONE_STATE
  • android.permission.RECEIVE_SMS
  • android.permission.READ_SMS
  • android.permission.WRITE_SMS
  • android.permission.ACCESS_NETWORK_STATE
  • android.permission.CALL_PHONE
  • android.permission.SEND_SMS
  • android.permission.ACCESS_FINE_LOCATION
  • android.permission.PACKAGE_USAGE_STATS
  • android.permission.SYSTEM_ALERT_WINDOW

Interestingly upon launching this malware, i.e. upon clicking on the Flash Player icon in the app list, the Flash Player icon hides itself so that the user may not be aware of the malicious activity happening in the background.

The main activity class decodes a base64-encoded dex file, budda2.dex which is contained within the class as follows:

The decoded dex file contains the code responsible for incoming SMS interception, sending SMS and other malicious behavior.

Upon following one of the receivers, resiverboot for android.provider.Telephony.SMS_RECEIVED, budda2.dex is called internally as shown in the image below:

RiciverSMS from Budda2.dex file has the code to intercept incoming SMS messages as shown below:

As highlighted above the StopSound function changes the ringer mode to ‘0’ to avoid the user being notified of incoming messages.

DelIndox and DelSent deletes the messages from a particular originating address from the Inbox and sends the items respectively as shown below:

And it sends these to the hacker as per the command shown below:

This malware turns the compromised device into a bot, and the installed malware keeps listening for a command from the C&C server to carry out orders. The C&C can issue commands to the malware to even kill itself as well as shown below:

All the collected information is sent to the hacker including whether the bot is active or not. The hacker’s infection status dashboard is maintained as shown below:

This malware verifies if any one of the below mentioned banking apps or those dealing with financial transactions in the installed on the device. Few of the popular banking apps across the world are listed below:

International:
com.amazon.mShop.android.shopping
com.ebay.mobile
com.westernunion.android.mtapp
com.htsu.hsbcpersonalbanking
io.coinmarketapp.app

India:
hdfcbank.hdfcquickbank
com.csam.icici.bank.imobile
com.axis.mobile
sbi.SBIFreedomPlus
snapwork.IDBI
idbibank.abhay_card
co.bankofbaroda.mpassbook
unionbank.ecommerce.mobile.android

USA:
com.wf.wellsfargomobile
com.westernunion.android.mtapp
com.usbank.mobilebanking
com.usaa.mobile.android.usaa
com.unionbank.ecommerce.mobile.android
com.thunkable.android.avenue_mitm.Polonix

Germany:
de.schildbach.wallet
de.postbank.finanzassistent
de.leowandersleb.bitcoinsw
de.langerhans.wallet
de.fiducia.smartphone.android.banking.vr
de.dkb.portalapp
de.consorsbank
de.commerzbanking.mobil
de.comdirect.android
mobile.santander.de

Australia:
org.stgeorge.bank
org.bom.bank
org.banksa.bank

Russia:
ru.yandex.money
ru.vtb24.mobilebanking.android
ru.simpls.mbrd.ui
ru.simpls.brs2.mobbank
ru.sberbankmobile
ru.rosbank.android
ru.raiffeisennews
ru.mw
ru.alfabank.mobile.android
com.webmoney.my

UK:
uk.co.bankofscotland.businessbank
com.barclays.android.barclaysmobilebanking
com.rbs.mobile.investisir
com.rbs.mobile.android.ubr
com.rbs.mobile.android.natwestoffshore

France:
net.bnpparibas.mescomptes
mobi.societegenerale.mobile.lappli
fr.lcl.android.customerarea
fr.laposte.lapostemobile
fr.creditagricole.androidapp
fr.banquepopulaire.cyberplus
fr.axa.monaxa

Turkey:
dk.ozgur.btcprice
com.vakifbank.mobile
com.pozitron.iscep
com.ziraat.ziraatmobil
com.ykb.android

Please note that apps such as document readers and Flash Players:

  1. Do NOT require device administrator privileges.
  2. Should not typically request for permissions to “SEND, WRITE OR RECEIVE SMS

Please avoid installing such applications.

As always we at K7 Threat Control lab make the following recommendations:
  • Use a top-rated mobile security product such as K7 Mobile Security to block any infection
  • Regularly update the mobile OS and security applications installed to be free of mobile malware
  • Carefully analyze the messages or alerts which apps display before taking any action
  • Refrain from installing apps recommended by strangers
  • Review the reputation of any app before downloading and installing it
  • Choose to download and install apps only from the official Google Play store
  • Do not enable “Download from Unknown Sources”

C&C server Image courtesy:
github.com/jacobsoo/J-Hunter/tree/master/Android

Dhanalakshmi.V & Baran Kumar.S

K7 Threat Control Lab

If you wish to subscribe to our blog, please add the URL provided below to your blog reader: http://blog.k7computing.com/feed

Don’t Lose Interest Over Banking Security

Friday, October 16th, 2015

The evolution of Internet technology has brought about a paradigm shift in the way we bank. As responsible netizens, it is of utmost importance that we understand the implications of these changes and develop basic security etiquette. This blog aims to provide a few security tips that will educate readers about how to bank safely online.

For years the mere utterance of the word banking would invoke feelings of anxiety amongst most people.  The thought of having to stand in endless queues waiting for your turn, filling in numerous forms only to be informed by the teller that you’ve left out some esoteric detail and that you’d have to go all the way back to the start of the line, would be enough to send chills down your spine.

The last decade however has witnessed a revolution where you can conduct transactions, transfer funds to friends and family, all at just the click of a button. The progression of technology and the convenience factor have been the catalysts in driving out traditional ways of banking, ushering in its online avatar.

To access an online banking facility, you would register with the institution and set up your credentials. This is a combination of user name and some password, using which you could use some of the common facilities offered by online banks. The facilities include viewing account balances, transferring money, downloading financial statements, etc.

While this new technology may have eliminated the red tape & inefficiency, the story is not all rosy. The advent of online banking has brought with it its own set of problems – a security problem on a global scale with massive financial consequences; billion-dollars-worth consequences, to be more precise.

Exploiting a lack of user awareness to their advantage, cyber criminals have managed to swindle billions of dollars of money, transcending both physical and virtual borders. Using techniques such as Phishing and Vishing, the fraudsters lure potential victims into disclosing their online banking credentials and other personally identifiable information. Once the bait has been taken, the innocent victims enter the deep web of the Internet – a world full of poisoned DNS servers, infected hosts and web sites laden with exploits masquerading as your regular banking site, aimed at just one thing – stealing your money.

All is not lost though, for here are some of the steps that you should follow to ensure the safety of your hard-earned money:

  1. Enable multi-factor authentication. Most banks send a randomly generated PIN to your registered mobile, which will have to be keyed in along with your regular credentials to gain access to your online bank account. This may now be mandatory
  2. Create a strong password. Avoid using any common words or phrases and never create a password that contains your name, initials, or your date-of-birth. Also, remember to change these passwords at regular intervals
  3. Secure your mobile device/computer and keep it up-to-date. Make sure you have a firewall turned on and are running a top-rated, Anti-Virus software solution such as K7 Anti-Virus. This will ensure you are protected from Trojans, keyloggers and other forms of malware that could be used to gain access to your financial data. You could also conduct online banking transactions in a dedicated, secure browser such as K7 Secure Web which will protect transactions even if the computer were infected with common malware
  4. Up-to-date browsers replete with patches for any 3rd party plugins
  5. Avoid clicking through suspicious emails. Beware of unsolicited emails that purport to be from your bank. Treat such emails with suspicion as it may well be a phishing attempt to trick you into handing your credentials over. Banks will never ask you for confidential information via email or by calling you up
  6. Access your accounts from secure locations. It’s always best practice to connect to your bank using computers and networks you know and trust. Look for a small padlock icon on the address bar – the web address of the site you are on should begin with ‘https’
  7. Always logout when you have completed your banking work. It is good practice to always log out of your online banking session when you have finished your business. This will lessen the chances of falling prey to session hijacking and cross-site scripting exploits
  8. Set up instant account notifications. Banks offer a facility for customers to set up text or email notifications to alert them to certain sensitive activities on their account. Such alerts could give quick notice of suspicious activity on your account

With more people registering to conduct online banking transactions every day, it is only fair to say that this problem of virtual robbery could only get worse. As responsible online banking users, we must ensure that we follow the above-mentioned basic security precautions to keep ourselves and our money safe online.

Lokesh Kumar,
K7 TCL Systems Manager

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:
http://blog.k7computing.com/feed