Phishing reports were triaged from Phish Alert, Outlook Report Message/web reports, helpdesk and third‑party app queues; helpdesk accepted reports for shared mailboxes and app objects when UI reporting failed. Analysts examined mail headers (SPF, DKIM, Return‑Path, MTA hops), sender reputation, full link destinations and redirect chains (including aka.ms and consumer de‑redirector variants), and expanded tokenized portals (MS Forms, mailanyone, bill.com, Adobe Sign) to cross‑reference invoice/case IDs and marketing streams. Redirector families (for example sendibt2/sendibt3), tracking/analytics calls (api.mixpanel.com, api.telegram.org), telephone numbers, social links and wallet addresses were recorded as indicators; investigators also noted hosting platforms used for phishing landing pages, including public AWS S3 buckets. Attachments and rendered payloads (.eml, DOCX, PDF, images, audio) were examined in isolated sandboxes or from mailstore copies; AV/Windows Defender scans were performed and manual rendered views or screenshots were preserved when pages or links became inaccessible after interaction. For inaccessible pages or short‑lived content, investigators preserved screenshots, expanded URLs, mail headers, timestamps and user statements and recorded inconsistent spam‑filter verdicts observed during triage. Third‑party reputation and scam‑detector services were consulted and bulk samples were submitted to Microsoft when escalation was required. Mail gateway controls, deny/blacklists and quarantine workflows were used to block malicious senders, domains, redirectors and calendar/Teams origins; common mitigations included blocking at the gateway, quarantining or deleting malicious messages from mailboxes, and logging automated removals triggered by the Phish Alert workflow. When meeting invites or calendar events were quarantined, investigators verified envelope‑from versus display‑from, inspected quarantine metadata and headers to identify true origin, and coordinated admin or vendor support for quarantine release when users could not self‑release items. Mail, web and identity provider logs (Okta/Azure AD/Entra) were queried to identify users who clicked links, called numbers, followed SMS links, or granted application consent; when compromise was suspected accounts were monitored and passwords were reset and OAuth consents revoked. Endpoints where links or attachments were accessed were scanned and monitored for follow‑on alerts. Phishing content embedded in third‑party systems (for example Salesforce cases) was removed where possible and application owners were coordinated with when objects could not be deleted. Sextortion/extortion and abusive messages were treated as spam/abuse, blocked and logged with wallet addresses and extortion indicators recorded. Recurring IOCs and redirector patterns (consumer de‑redirectors, mailanyone portals, bill.com/PayPal invoice tokens, aka.ms short links, notion.site redirects, sendibt2/sendibt3 redirectors, api.telegram.org exfiltration calls) and reporting workflow issues (shared‑mailbox reporting limitations and Report Message UI disappearance behavior) were documented. For suspected exposure of personal addresses, public social profiles and breach‑check services (haveibeenpwned) were reviewed to identify likely exposure vectors and correlate personal and corporate addresses when present. Account‑creation or identity‑confirmation emails that requested confirmation before provisioning were treated as credential‑phishing vectors and preserved as artifacts when reported. For security‑awareness events, investigators confirmed simulation status when applicable, communicated confirmations to users, provided example phishing messages on request, and recorded simulation enrollments in ticketing/audit logs.

Investigators confirmed sender legitimacy before releasing legitimately generated notifications and recorded delivery paths and findings in mail logs and quarantine records. Forensic steps included MTA/header analysis to trace authenticated SMTP deliveries (SASL username and source IP), enumeration of sending IPs and SMTP envelope addresses, and inspection of SPF, DMARC and DKIM results; header rewriting and local DKIM signing (for example OpenDKIM/mx1) were recorded as common causes of DKIM signature mismatches. Inconsistent DMARC alignment for third‑party sends (notably Amazon SES and other mail services) and misconfigured external provider servers were recurring causes of quarantines and were escalated to vendors when observed repeatedly. Administrators released messages from gateway or Exchange quarantine when validated; where the quarantine UI failed to request or release a message, cases were escalated for specialist manual release. Tokenized tracking links and SafeLinks‑wrapped URLs were reproduced or unpacked to verify redirected targets, and one‑time/expiring confirmation links were validated with the originating service (examples included security‑awareness/training notifications delivered via KnowBe4 and marketing vouchers such as Wunschgutschein). Outlook client differences were noted — the new Outlook client could surface external/safety banners and block inline images for previously received messages — and recipients were informed when messages were legitimate. Attachments and PDFs were scanned with antivirus/antimalware tools and document details were cross‑checked against internal customer/payment/record systems when relevant. Final outcomes and the rationale for release (delivery path, header/DKIM/SPF/DMARC results, and any vendor escalations) were documented in mail logs and quarantine records to explain the behaviour to affected users.

Investigators inspected message headers, attachment and message metadata, and client behaviour to reproduce how files were saved. Suspicious artifacts — including .eml, .svg and HTML‑spoofed files, invoice attachments, PDFs, and cloud large‑attachment download links such as ShareFile and mail.163.com — were submitted to the organisation's spam and anti‑malware scanning service and scanned; endpoints were scanned when appropriate. Where a cloud download link or attachment was plausibly legitimate but unexpected it was flagged for deletion and the sending address was blocked if the message remained suspicious. Saved files that posed risk were removed from devices and incidents were logged. In one case a staff member downloaded a PDF attachment locally, scanned it, and resent the file separately to the requester after review; in another a ShareFile link was assessed as plausibly legitimate but recommended for deletion if the recipient had not expected it. When attachment behaviour could not be reliably reproduced investigators recorded findings, scanned available samples, and advised deletion of the message and any saved files; incidents were closed after scanning and assessment.

Investigators first triaged whether incidents were due to provider-side filtering/quarantine errors or account compromise. For provider-side quarantine failures, vendors corrected quarantine behavior so malicious items were retained instead of being re-released and vendor escalations were documented. Reported messages were classified as phishing and malicious URLs — including third-party hosted case/form links — were blocked at tenant/URL block levels; attacker infrastructure was reported to hosting providers and takedown services. Users, including impacted student populations, received broad communications discouraging interaction with suspicious messages, advising verification of sender identity, and were directed to use Outlook’s Report function and the Report Message add-in where available to surface suspicious mail. For account-compromise incidents, affected accounts were disabled or contained, persistent malicious mailbox forwarding rules were removed and external forwarding targets were blocked, compromised credentials were rotated, active sessions were revoked, and MFA was enforced or re‑issued. Outbound abuse and sent-item artifacts were cleaned or isolated and high-volume outgoing activity was throttled or blocked during remediation. Targeted follow-up was performed for accounts that engaged with links or attachments and instances of downstream financial fraud were escalated to banks and investigators. Quarantine review, URL/tenant blocking, vendor corrections, removal of forwarding persistence, credential/session/MFA remediation, outbound cleanup, user notification, and escalation to external hosts/banks resolved the exposures and supported post-incident documentation. Separately, multiple user reports lacked message samples or indicator details; virtual agents requested additional information but, when none was provided, tickets were recorded as closed "Won't Do" and no technical remediation was performed for those reports.

Investigators classified incidents as browser push-notification phishing (not host compromise) using web telemetry and browser/source attribution. Remediation actions that resolved the incidents included blocking malicious sending domains at the web filter/gateway and in corporate DNS where possible, and removing the offending origin from browser site entries and push-notification permissions. Edge-specific remediation included deleting the site entry and clearing site content/notifications; Chrome remediation included disabling push notifications for the origin and clearing site data. Microsoft Defender quick and full scans and central monitoring returned no detections and showed no installed payload in investigated endpoints. On endpoints without administrative rights, remediation prioritized network-level domain blocks and removal of browser permissions/site data. Support advised affected users that the alerts were phishing, instructed them not to install software or enter credentials on pages opened from those notifications, captured screenshots and evidence for investigation, and published intranet/SharePoint/Teams guidance. New observation: at least one user-click interaction with a notification produced rapid, repeated popups (~1 per second) and a support-initiated disk/virus scan in that case appeared to stall (no progress for ~1 hour); investigators noted the stalled scan but did not find installed malware. After blocking malicious domains and clearing browser notification permissions/site data, fraudulent push notifications ceased and application performance returned to normal; previously failing installations completed successfully when retried in observed cases.

Support verified that the messages, links and groups involved were legitimate and not malicious. For the Outlook folder-add error, the technician ran a Windows Defender full system scan (Settings > Update & Security > Windows Security > Virus & threat protection > Scan options > Full scan) and confirmed no malware related to the incident. Failures of the Phish/Phish Alert Report button were resolved either after external Microsoft/Office365 service interruptions cleared (users retried and reporting returned) or by server-side fixes applied by helpdesk/Cyber Security Services; in each case the add-in’s functionality was restored and users were asked to retry reporting. A single incident recorded an unexpected Salesforce consent prompt when accessed from Outlook; no remediation details for that prompt were recorded in the ticket.

Support verified the final landing domain was an Amazon page and judged the event to be most consistent with an advertising/redirect chain rather than an active compromise. There were no Defender alerts or observable signs of infection and the user reported normal system operation. Support advised running a full Windows Defender scan if any suspicious files or programs had been opened and to report any subsequent unusual behavior; no indicators of compromise were identified during the investigation.

Incidents were classified as phishing attempts impersonating ChatGPT or an internal governance update. Investigators removed or quarantined the suspicious messages and blocked the specific senders, redirect-like sender domains, and similar message patterns at mail filters. Where users reported possible credential entry, the impacted Okta accounts had passwords reset and active sessions revoked. User devices underwent Windows Defender full scans, which did not identify malware or persistent compromise. Investigators evaluated link‑preview activity (including Jira/other preview services) and included preview-related URLs in the blocking rules. A targeted advisory describing the phishing characteristics (impersonation of AI/internal teams, expiring/urgent links, threats of blocked access, redirect-looking sender domains, bilingual content in some cases, and link‑preview risks) was distributed to relevant staff, and users were instructed to report suspicious messages using the corporate phishing report flow.

Affected users reported the messages through phishing‑reporting tools or directly to IT. IT Security reviewed message content and headers (including external‑sender warnings and spam/virus‑scan results), determined the sender addresses were external and the requests were likely social‑engineering/contact‑harvesting attempts, and blocked the external sender addresses at the mail gateway to prevent further delivery. Users were informed that the messages were malicious and were advised to delete them. In at least one matched case the spoofed message had been routed into a Salesforce inbound email queue; the presence of the spoofed inbound record was noted though no CRM‑specific remediation was recorded in that ticket.

Reported messages were reviewed by IT Security and classified as financial-themed phishing, including payment-confirmation impersonations and advance-fee/‘419’ inheritance or contract-fund scams. Analysts noted common indicators across reports: fabricated transaction or order IDs, large-sum inheritance/contract claims, requests for bank/account details or to act as beneficiary, requests for phone/fax contact, multilingual/legal boilerplate, spam/virus-scan footers and mailanyone.reportspam links, external-origin warning banners, and senders using spoofed domains or free webmail (e.g., Gmail). Incidents were processed through the Phish Alert reporting workflow or HelpDesk intake; IT Security acknowledged reports, reviewed message headers/bodies, and treated them as malicious. Containment actions included blocking the offending sender addresses at the mail gateway/spam filter and adding them to blocklists (some tickets recorded attempted blocks where blocking was applied at gateway/filters), instructing reporters to delete the messages, and monitoring mail deliveries for recurrence. Systems involved were the corporate mail gateway/spam filter, antivirus scanner, Phish Alert reporting tool, mailanyone spam portals noted in message footers, and the IT HelpDesk. No system error codes were observed, and monitoring showed no further deliveries from blocked senders before tickets were closed.

IT inspected message headers and content and classified the reports as commercial marketing or spam rather than credential‑harvesting or malware. Phish Alert reports were closed after classification. Where users reported recurring or unwanted messages, IT added the sender or domain to the mail gateway/spam‑filter blocklist to reduce further deliveries. Users were informed the items were legitimate commercial mailings or tracked newsletter/event content and were told to delete unwanted messages or use the mail footer "report this email" link to feed spam filters. Helpdesk staff processed the reports and marked the tickets resolved.

IT reviewed reported items and classified them by channel and risk: unwanted solicitations, likely scams/phishing, misaddressed messages, or unverifiable cold calls. For email reports, messages with attachments were treated as suspicious and not opened; such messages were deleted and senders were blocked at the mail gateway and on spam filters to stop further deliveries. Reports containing links were investigated by inspecting the linked URLs and sender account activity; messages whose linked sites and sender histories indicated benign but unrelated contacts were recorded as misaddressed and removed, while sender accounts showing single‑send patterns or other anomalies were flagged as potentially compromised. Mail Delivery Subsystem/DSN notices showing errors like “DNS type 'mx' lookup ... responded with code SERVFAIL” were identified as backscatter from invalid recipients rather than new legitimate deliveries. For high‑volume fake leads delivered via Twilio into myStudium, operators added patterned email addresses and domains to the Twilio/myStudium spam filter and blocklist, enabled monitoring to confirm that new leads matching the pattern were blocked, and recorded that previously ingested fake leads remained and required manual closure; Salesforce lead origins were checked when relevant. For inbound telephone reports, staff returned the provided numbers, attempted call‑backs, and spoke with the caller where possible to review claimed relationships; internal contact lists and vendor‑management records were searched and most claimed contacts could not be verified, so the calls were treated as unverified cold calls and documented in the ticket. All investigative actions, rationales, any mailbox/gateway blocks, and phone numbers or vendor information were recorded in the ticketing system; reporters were informed of the classification and advised to continue using Phish Alert/report‑spam or to contact HelpDesk/IT Security if uncertain.

IT Security reviewed reported messages and treated them as phishing. Triage noted indicators such as generic placeholders (for example, '[Invoice Number]') and mass BCC recipients, and gateway headers (Mimecast) were recorded. Inbound mail gateway and spam filters were updated to block the sender address and/or domain to prevent further deliveries; one sender was identified as originating from an Oracle Cloud workflow email service and was blocked. Attachments were subjected to standard anti‑malware and spam scanning during review and no additional indicators of compromise were found. Reporters were informed the messages were malicious or suspicious, were advised not to open attachments and to delete the emails, and incidents were closed after blocking the sender and confirming no further indicators.

IT/Security analyzed the submission, confirmed it as a phishing attempt, and blocked the sender/address to prevent further deliveries. The user was instructed to delete the email and the ticket was resolved after the block was applied.

IT reviewed the message and confirmed it as a legitimate Microsoft OneDrive/SharePoint system notification rather than phishing. The user was advised to check the OneDrive/SharePoint recycle bin for restorations (items recoverable within 93 days) and to contact HelpDesk if further assistance was required.

IT Security reviewed reported messages and classified them as phishing impersonating meeting/collaboration recording services (examples observed: Teams, OneDrive, Zoom). Messages were externally originated and used plausible restore/recycle-bin links to attempt credential capture or malware delivery. The senders/addresses were blocked at the mail gateway to prevent further deliveries. Reporters used Outlook's 'Report phishing/suspicious email' functionality (Microsoft Defender for Office 365) to escalate messages; reporters were instructed to delete the emails. Incidents were closed after classification and gateway blocking to prevent recurrence.

Technicians confirmed that unsolicited authentication prompts were legitimate in the reported incidents and that authenticating restored access to the affected application (for example, clicking the “Connect” prompt returned Oasis access). In a macOS-specific case, IT identified and repaired a defect that had prevented the Self Service+ sign-in window from being closed; staff informed the user that Self Service+ is the Mac software portal and that they should sign in with their normal IU login credentials when prompted. Access or window behavior was restored following authentication or the bug fix, and the resolution was confirmed with the users.

Investigators traced the unexpected messages to a configuration setting in the Care system that had been accidentally overwritten during a deployment. The activity was confirmed to be a configuration error rather than a security breach. Affected students were notified about the incident, the Care configuration was restored, and deployment/process controls were tightened to prevent the same overwrite from recurring.

The investigation determined the interaction was an automated phishing flow rather than a legitimate partner message. Delivery analysis showed seven related emails were involved, with two blocked by mail filters and five delivered to recipients. Recipients who completed the confirmation flow were redirected but did not download any files, and no account compromise was detected. Messages from the fraudulent sender were blocked/removed during remediation and the incident was closed after verification of no compromise.

Investigations checked Teams/ILSE session guest lists, transcription/summary service activity, and myCampus recording access logs. In cases where unknown guests or third‑party transcription prompts were sending summary requests, activity was attributed to third‑party transcription/summary services (for example Otter.ai) and/or external guests admitted to the session; no evidence was found of a compromise of university systems, the events were documented as third‑party generated activity, and the incident was closed after confirming source and scope. When a user alleged that ILSE/myCampus recordings had been used off‑site (for example to generate images on Midjourney or to contact them via Discord) and claimed linkage of their IU identity to a private email, the report was escalated to IT Security and Data Protection for privacy and forensic review; at the time of reporting there was no confirmed unauthorized access of university systems. Incidents were recorded with relevant context (session metadata, guest lists, recording IDs) to support any further privacy or security investigations.

Support inspected sender addresses, message headers, and message context and confirmed that reported items were legitimate administrative or service-generated notifications rather than phishing in the investigated cases. Investigations verified Salesforce-generated account-email-change messages (for example from qa_support@salesforce.com) and identified that such messages routinely included time-limited change links (commonly a 72-hour expiration) and could display placeholder or invalid current addresses (for example addresses ending in .invalid or test/UAT addresses) when the Salesforce account or instance was configured with a non-production or placeholder email. Multiple unsolicited or repeated email-change requests were escalated or forwarded to the Salesforce specialist/business team for further investigation. Support also identified backend distribution and Azure AD dynamic account-management group notices (for example IUG-DYN-All-IU-Staff-IUHochschule-Employees-Excluded) that were triggered by administrative membership automation, often presented as empty or inaccessible to standard users, and were intended for administrative audiences. Vendor or management-tool notifications (for example managed Lenovo firmware-update messages on institutional devices) were validated as legitimate device-management traffic. When a Salesforce message pertained to an environment not administered by central IT, support confirmed they lacked instance access and directed the reporter to the owning SalesTech/business team or the Sales & Service Tech Portal (Jira Service Management) for in-product handling or blocking. Support advised reporters that messages they had not acted on could be treated as suspicious until validated, and accepted reports into Outlook/Exchange reporting workflows before closing the incidents.

The case was escalated to the communications team, which investigated and found that recipients had multiple enrollments in UPS courses causing duplicate entries in the mailing distribution; the communications team recorded the issue and planned adjustments to the mailing process to deduplicate recipients so each person would receive the information only once.

Incidents were handled using a risk‑based containment and verification approach. For confirmed or suspected credential exposure or anomalous sign‑ins, impacted accounts were contained and access was restored by forcing password resets, clearing or blocking active sign‑in sessions, and unlocking accounts as needed; users re‑authenticated to OKTA/Teams after credentials were changed. Support reviewed OKTA and Azure AD sign‑in events and verified MFA/OKTA‑Verify activity; many log reviews showed no suspicious sign‑ins and cases with anomalies were escalated to specialists. For minimal‑exposure events where a user only opened an external phishing page briefly and did not enter credentials or observe errors, the message was removed and the webpage closed; after log review showed no suspicious activity no further technical containment was performed. Where links were tied to third‑party/vendor breaches, support collected sender and subject details, added IOC entries to the incident record for detection and hunting, and performed or recommended endpoint/PC malware scans and account checks to investigate possible data exposure (for example employee address‑book or customer data). Tickets were sometimes reopened or escalated when initial attribution was uncertain or when IOCs/endpoint findings required further investigation.

Support generated a new Okta password-reset link and delivered it to the user's specified private email address (GMX) to complete account recovery via an alternate, user-controlled channel; the ticket was then closed.