"Toll-fraud" compromise and VM mailbox DB is gone; what are my options?

[Tobakslovokian]

Received a call that secretary operator extension is not working; a test into auto attendant showed that "0" went to an invalid number. Looking in the WUI, sure enough, extension 0 is forwarded to some cell number in California... odd that it wouldn't have been a high toll number outside the US? From reading up on this, it appears this can happen if a caller calls in via main telephone number and accesses either the admin or operator mailbox via a default PIN code (something that should have been changed by installers), or by guessing another users PIN code and doing a call forwarding and some sort of privilege-type escalation to replace the system wide operator extension to their number.

However, the catch is, all our VM mailboxes are now gone... all that exists is the "0" pointing to their number, and a 99 that points to an admin mailbox. How in the world would this have happened... I can understand the vulnerability of changing operator extension via what I've read, but how would they have "gotten in" the system. It is not accessible to the outside world and only over Cisco SSL VPN and only our vendors have this profile. Our SIP communication is only allowed to originate from two IP addresses belonging to our provider, Flowroute.

Not sure how this happened; was this all done over the phone?

With the VM Mailbox DB now gone, what are my options?

We have a backup from 18 months ago; can we grab only the mailbox DB via a restore and put that in place, and then just add the new user VM mailboxes since that restore?

How do I go about verifying/changing Technicians,Managers and Admin passwords; not sure if our installer ever did.

[Tobakslovokian]

So I grabbed the .tar file backup from previous, and just made a new backup now.

I see the folder hierarchies are vmail\temp\db\backup and in there is another vmail folder, which I suspect is "just the vm database."

Thoughts on grabbing this out of old backup, and putting in tar file in new backup, re-taring it back up and restoring? This would preserve all of our system settings while restoring VM mailboxes. Caveats/risks?

[johnp]

Do you have access to Mitel online? The is a knowledge base article on manually backing up and restoring embedded vm. Yes you can extract the file needed and restore via this method.

[Tobakslovokian]

I do not and we live in a very remote area and nearest Mitel vendor (which is our VAR) is an hour away and they are by and large not very knowledgable... so I'm stuck on my own and I will be looking for someone more national in the future to support us remotely. However, I need to take action tonight. I know Mitel is very tight about not giving out information to end users, but if one would not provide me guide, would you point me in correct direction as to which directories within the backup hierarchy are for the VM Mailboxes; I want to ensure to get only those. Thanks for any assistance you can provide.

[Tobakslovokian]

I would fully support paying standard/emergency hourly rates on this, if someone would be commercially available to assist; I think I could be fine with 5 minutes and a few questions answered.

[johnp]

I'm not looking for any money. I am sure with the info, you would likely be able to do this. I didn't have the doc in front of me to relay how it is done. I'll see if I can find it.

[johnp]

Prior to this procedure, perform an ESM backup without saving voicemail messages.

Procedure Summary
 A. To back up voicemail message in vmail/backup manually
 B. Ftp voicemail backup message from vmail/backup
 C. Ftp voicemail backup message to vmail/restore
 D. Restore voicemail message in vmail/restore


Step A: To back up voicemail message in vmail/backup manually

 Step A1: Connect one of your PC com port to RTC shell (Maintenance port of 3300, 9600,8N1)
 All commands list in Step A. below are issued from RTC shell.

 Step A2: Type: lkup "mui_perform_backup"

 System should respond as follows:
 mui_perform_backup_restore 0x015d5418 text

 Identify this hex number and save for the use in Step A3: (in this example, 0x015d5418)
 Note: This hex number is load-dependent and will be different between software loads.

 Step A3: To create a backup folder within vmail and then backup all voicemail in vmail/backup folder

 Type: cd ?/vmail?
 Type: mkdir ?backup?
 Type: 0x015d5418(0,2,?/vmail/backup?) 0x015d5418 is JUST an example
 Use the hex number observed in Step A2.

 System should respond as follows:

Starting backup processing...

Backup in progress...

Backup complete.
Backup processing complete
value = 0 = 0x0

 Note: This may take a few while to observe ?Backup complete? message depending on the size of voicemail messages.


Step B: Ftp out all of voicemail files from /vmail/backup into your PC

 The following commands are typed on the PC

 Step B1: Open a DOS prompt and create backup directory (e.g. c:\vmback)
 Step B2: On DOS prompt, type:
 Cd c:\vmback --------this is an example and you can use your own directory

 ftp <ip address of 3300 controller>
 Then log in with ESM username and password when prompted
 Cd /vmail/backup
 Binary
 Prompt
 Mget *.*
 bye


 Note: It may take a while to transfer of all files.
 Basically, you should see the similar files in your backup as follows:
 The exact number of files varies from site to site but make sure that you have transferred all files from /vmail/backup.

 This file content below is only for your reference.
0000MASTER.DAT
 0000PARM.BIN
 0a00voxdrv.cfg
 0901pday.vox
 0000CALENDAR.DAT
 0000gadmin000.lst
 0000gadmin001.lst
 0000gadmin002.lst
 0000gadmin003.lst
 0000gadmin001.nam
 0000gadmin002.nam
 0000gadmin003.nam
 0800gadmin000.vox
 0000g3479050.lst
 0000g3847999.lst
 0000g4234999.lst
 0000g2518999.lst
 ?..
 0000g3862999.lst
 0000g5117999.lst
 0000g4641999.lst
 0000g2190999.lst
 0000g5110999.lst
0600.tar
0400.tar
0500.tar
0300.tar
0200.tar


Step C: Ftp in all voicemail files in /vmail/restore

 Step C1: To create a restore folder within vmail
 On RTC shell,
 Type: cd "/vmail"
 Type: mkdir "restore"


 Step C2: From your backup PC, open a DOS prompt and go to backup directory defined in Step B1 (e.g. c:\vmback)

 Step C3: Ftp in all voicemail files obtained in Step B2
 On DOS prompt, type:
 Cd c:\vmback --------this is an example and should be same in Step B2.

 ftp <ip address of 3300 controller>
 Then log in with ESM username and password when prompted
 Cd /vmail/restore
 Binary
 Prompt
 Mput *.*
 bye
 Note: It may take a while to transfer all files.

Step D: To restore all voicemail message from /vmail/restore

 Step D1: Connect one of your PC com port to RTC shell (Maintenance port of 3300, 9600,8N1)
 All commands list in Step E. below are issued from RTC shell.

 Step D2: Type: lkup "mui_perform_backup"

 System should respond as follows:
 mui_perform_backup_restore 0x015d5418 text

 Identify this hex number and save for the use in Step E3: (in this example, 0x015d5418)
 Note: Typically, we should restore to the same software load. In this example, it should be the same hex number as in Step A2

 Step D3 : To restore
 Type: 0x015d5418(1,2,"/vmail/restore") ---->this is the hex from Step E2


 Note: Please do not get alarmed when you notice that some files are being deleted during restore as follows:

 deleting file grp/3038/V41400f86.0a9
 deleting file grp/3038/V42160a5d.023
 deleting directory grp/3642
 deleting file grp/3642/V4250f586.001
 deleting file grp/3642/V4264fd8b.04c
 deleting directory grp/3086
 ...

 Backup complete.
 Backup processing complete
 value = 0 = 0x0

 The voicemail will stop and start on it's own when the backup /restore is done. For a successful backup and restore the VM will return value =0 =0x0 as above.




This is the doc, finding what you need for restore shouldn't be that hard. Extract the needed info, copy to a known location that is easy to get to via command line, find entry point and then restore.

After i would reboot

[Tobakslovokian]

Thanks!

I ended up just using a previous full backup and not injecting anything; we're good to go. Appreciate the write-up!

[ZuluAlpha]

Don't forget to change the admin/technician passcodes and passcode for mailbox 9999 or they'll get you again.

[ZuluAlpha]

As to how they got in, it was probably an automated dialer and script pressing * or # at the Auto Attendant and entering mailbox 9999. Then default passcodes are used until there's a hit. Once you're in this way you can modify the mailbox routing, or delete the setup altogether. Most of us have probably seen it happen at one time or another. It's unlikely, but not impossible, that the system was hacked via the web interface.

Although type of thing is not exclusive to Mitel systems, I had it happen to me not too long ago. It was international toll fraud. Fortunately our carrier caught it quickly and turned off international calling. Part of my correction was implementing 6 digit passocdes, lock outs after three failed attempts, and setting the COR of my voicemail ports to local calls only.