1. You should locate the customer's phone number and put it in the case.
   • NOTE: To find a phone number, see if they have a duo device number in NIDU, check the wisc directory, the phone source lookup tool, or the "Alt Contact" section in previous cases
   • NOTE: If the reason the NetID was disabled is anything but 'Compromised Account' please see Help Desk - Handling Non-Compromised Disabled Accounts for instructions.
2. If you are able to locate a phone number, assign the incident to callback by a phone agent.
3. If a phone number is not able to be located, add a journal note stating "No phone number found, setting case to pending: customer contact required", and set the case to Pending: Customer Contact Required.

Talking Points

Talking Points

Q: How did this happen? Can you tell me what I clicked on? I don't think I did this. A: It is hard to find exactly how credentials could have been compromised. All I can say for sure is your NetID and password were compromised and being used to sign in by someone other than you. Commonly, if you use your NetID username or password on third party websites, your password may get compromised after it is leaked from the third party site. It may also happen if you logged into a website that was pretending to be UW-Madison login but was instead a malicious website posing as UW-Madison, arriving from a phishing email. UW-Madison's Security team takes these steps for your protection to make sure any malicious actors who may have been logged in to your account are forcibly logged out.

1. If the customer calls the Help Desk, skip to step 4.
2. If a callback is assigned to you, call the customer
   • If the customer answers the phone go directly to step 4 when they pick up.
   • If you reach the customer’s voicemail, skip to step 3, and use the script provided.
     • Set to Pending: Waiting For Customer if they answer
     • Set to Pending: Customer Contact Required if you receive their voicemail
   • If someone other than the customer answers or if the customer is not able to complete the steps at this time, provide the case number and Help Desk phone number and ask for them to have the customer call us back. Set the incident to Pending: Customer Contact Required
   • If you reach the wrong number, a disconnected number, or are unable to leave a message for the customer, add a journal note stating "{The reason contact could not be made}, setting case to Pending: Customer Contact Required", and set the case to Pending: Customer contact required.
3. If you make contact with the customer's voicemail, identify yourself using the following script:
   

   Hi, this is X from the University of Wisconsin, Division of Information Technology. Your NetID and Microsoft 365 account were disabled due to suspected compromise. For your protection, we have disabled your access to these services. To resolve this issue, please go to http://helpdesk.wisc.edu and search for 52781 and follow the instructions. Once you are done following the instructions, please call the Help Desk at 608-264-4357 and reference the {CASE NUM}.

   Note: If the customer answered the call during a callback and you have completed the script above, complete the steps below. If the customer is weary whether or not we are the DoIT Help Desk, have them call us back or find our number from Google!

4. When the customer either calls back or calls for the first time:
   • Use the WiscIT case that has already been created, do not create a new case. You may need to search for the user's NetID in the WiscIT search bar to locate the case.
   • Verify the customer's identity via Campus ID number and a Duo Push (or follow other applicable identity verification procedures)
   • Go to Using the "Enable NetID" Button and the NetID Enable/Disable Tool and follow the steps listed within the "'Enable NetID' Button in the Help Desk NetID Utility" dropdown to re-enable the customer's NetID. If any issues arise, reach out to HDQA or an FTE to manually enable the account
   • Reset their password following Help Desk - NetID and NetID Password Reset Procedures. Next, have them follow NetID - Modifying your Account and log in to the modification page to change their password to a **completely different,** new password (i.e. not just adding a number after the old password).
   • Notify customer that if they had any 'Inbox rules', they were all disabled. Make them aware that the reason for this is because there may have been malicious inbox rule(s) added when the account was compromised.
     • Instructions for managing the 'Inbox rules' can be found here: Microsoft 365 (Outlook on the web | Outlook for Windows/MacOS) - Using Inbox Rules.
   • Notify customer that if a forward was on the account, it has been removed. Make them aware that the reason for this is because this may have been added to the account when the account was compromised.
     • Also let them know that if they do actually want a forward on the account, it is not recommended since we cannot guarantee the mail will be delivered to the external account.
     • If they want to set a forward, instructions for checking for setting a forward can be found here: Microsoft 365 - Set/Manage a Forward on a NetID or Service Account.
   • Inform the customer that they may experience issues logging into Outlook, as well as sending emails outside of the wisc.edu domain for up to 24 hours after their account is re-enabled.
     • The error message the customer may see can be found at Help Desk - Common Account Problems After Accounts Disabled by Security are Re-Enabled under Attempting to Log In to Outlook Online Gives the error: 'Something went wrong'.
     • This is due to proactive measures the Security and Microsoft 365 teams take to make sure an account is not sending outbound spam when an account is disabled.
     • Do not escalate a case for a mail delivery issue until 24 hours have passed since the account was re-enabled.
   • If the customer reports any errors, see: Help Desk - Common Account Problems After Accounts Disabled by Security are Re-Enabled, if there is an issue re-enabling the account try the steps outlined here: Help Desk - Enabling/Unlocking Compromised Account

1. The security case will be in the HDQA queue. Look in the case specifics and see if UWNet DISABLED is checked. 
   
   • NOTE: You can also see the customer’s device’s mac address in the specifics. (The MAC and IP may not match what's notated in the specifics section)
   • The attached csv file is the network log alerts from the previous 24 hours
     
2. If disabled is checked use the “CSOC -DISABLED- Suspicious Activity Report/Compromised Device” email template. Be sure to put in the customer's mac address, device name, and device description into the template email. (If the CSOC is requiring the computer to be inspected onsite, do not enable the device over the phone)
   
   If disabled is unchecked use the “CSOC -NOT DISABLED- Suspicious Activity Report” email template. Be sure to put in the customer's mac address, device name, and device description into the template email. 
   
   If vpn is checked use the “CSOC -VPN- Suspicious Activity Report” email template. Include device name and device description into the template email if available. 
   
   

3. Leave a note on the case for the next agent stating that they should follow 8595 for next steps. Keep the case in the QA queue. 
   Journal Note:

4. Leave the case in the QA queue when prompted after sending the email to the customer 

*HDQAs are always welcome to use the CSOC Channel in the Advanced Support Channel if they have any questions 

Talking Points

Talking Points

Q: How did this happen? Can you tell me what I clicked on? I don't think I did this. A: This happens when our firewall notices repeat (100+) traffic routing to a certain bad website or if your device is receiving messages or communicating with a malicious server to let the server know you're online. Bad browser extensions, toolbars, or adware may cause these issues to pop up. Cybersecurity cannot detect what caused the traffic routing issues. It's best to run a virus scan and check for bad extensions or toolbars if you receive this type of notification.

When the customer calls in:

1. Put their name in requestors incidents and find the open case for them. It will be titled “Suspicious Activity Report.”
2. Check if the device is disabled or non-disabled through the case description 
   

   
   If the “Disabled” box is checked, that means the device is DISABLED in Clearpass 

3. When the customer has a NON-DISABLED device
   
   • Verify customer has run a security scan on the disabled device per Security - Removing a Block. Other antivirus options for personal devices can be found at Security - Available Antivirus Software for Personally Owned Devices.
     • If the customer is unable to get the scan to come back clean, refer them to Onsite.
   • Resolve the case after confirming that the device does not have any malware or viruses.
4. When the customer has a DISABLED device:
   • Verify customer has run a security scan on the disabled device per Security - Removing a Block. Other antivirus options for personal devices can be found at Security - Available Antivirus Software for Personally Owned Devices.
   • After the customer’s device has come back clean from a security scan, verify the customer's identity via Campus ID number and a Duo Push (or follow other applicable identity verification procedures).
   • Now enable the device in question in clearpass
     • For instructions on using clearpass see: ClearPass - Registering Devices
     • Change the device from Disabled Client to Known Client
     • In the Configurations > Identity > Endpoints tab, set the filter to Attribute equals Username contains {NetID} 
   • If possible, verify the user has wireless access
5. Set the incident to Resolved and leave a journal note detailing steps taken and the end result