{
	"id": "02e2064b-4501-4929-abe5-82c5a3dcd68d",
	"created_at": "2026-04-06T00:13:03.792264Z",
	"updated_at": "2026-04-10T03:21:59.1592Z",
	"deleted_at": null,
	"sha1_hash": "6a6d0ae3ec3254e704e58b937f5d82b6ca7a4b59",
	"title": "Phishing Slack for persistence and lateral movement",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1669496,
	"plain_text": "Phishing Slack for persistence and lateral movement\r\nBy Luke Jennings\r\nArchived: 2026-04-05 20:39:21 UTC\r\nThis is the fourth post in a series on attack chains formed by combining techniques in the SaaS attack matrix and\r\nthe second post of two focused on attacking instant messaging applications with Slack as the primary example. \r\nThe previous post focused on external attackers gaining an initial foothold during the initial access phase of the\r\nkill chain. In this post we’ll be focusing on persistence and lateral movement for an attacker that has already\r\ngained a foothold on a Slack tenant by compromising an internal account. \r\nWe’ll build on the techniques in the previous post as well as introducing more and so will cover the following\r\nSaaS attack techniques, including chaining them together:\r\nSAT1018 - IM phishing\r\nSAT1019 - IM user spoofing\r\nSAT1036 - OAuth system integrations \r\nSAT1033 - Shadow workflows\r\nWhy focus on instant messengers?\r\nIf you’ve just read the previous post, you can skip this introductory piece and jump straight to the next section.\r\nThey aren’t new, however, the original focus of IM apps was on internal communication and phishing and social\r\nengineering attacks are often external. Email remained the standards-based protocol that enabled external\r\ncommunication no matter what email vendor was in use. In recent years, however, instant messengers (IM) have\r\nbecome the primary method of communication for many businesses. I wanted to focus on IM here because if\r\nthat’s where employees are communicating, it’s the best place to launch attacks against them. Even better, there’s\r\na history of users placing a higher degree of trust in IM platforms than email, so it becomes a potentially easy\r\ntarget.\r\nWhile IM platforms were initially used solely for internal communications, organizations quickly realized that IM\r\nplatforms could be used to communicate with external groups, individuals, freelancers, and contractors, with the\r\nhope of fewer emails and more instant communications. \r\nWe now have Slack Connect and Microsoft Teams external access to support this, with Slack Connect introduced\r\nin June 2020 and Teams introducing it in January 2022. This external access has increased the attack surface of\r\nthese platforms considerably.\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 1 of 13\n\nDespite decades of security research, email security appliances and user security training, email-based phishing\r\nand social engineering is still commonly successful. Now we have instant messenger platforms with:\r\nRicher functionality than email, \r\nLacking centralized security gateways and other security controls common to email and \r\nUnfamiliar as a threat vector to your average user compared with email. \r\nThere’s also a sense of urgency associated with IM messages due to the conversational nature compared with\r\nemails. Combined with a history of increased trust, we have the ingredients for increased social engineering\r\nsuccess.\r\nThere’s been an uptick recently in IM-based phishing research and real-world attacks, particularly for Microsoft\r\nTeams. For example, check out the great research from JumpSec on bypassing attachment protection for external\r\nTeams messages, the offensive tool TeamsPhisher and attacks distributing DarkGate malware via Teams.\r\nHowever, in this article we’ll focus on a few techniques specific to Slack.\r\nLearn how Push can help you secure identities across your org\r\nSlack apps - spoofing and persistence\r\nIn the previous post, we covered user spoofing and link preview spoofing attacks that can be conducted externally.\r\nBut do we have any other options available once on the inside that wouldn’t be available to us externally? \r\nWhat happens if you compromise a Slack account and then want to persist and/or move laterally? Ordinarily, you\r\ncan maintain access until session expiry or a password change is forced or the account is deactivated/deleted. For\r\nfurther actual impact, you could silently read messages as the user continues to operate their account but if you\r\nstart sending out malicious links to other targets, in an attempt to move laterally, then the real user is probably\r\ngoing to become aware of the compromise very quickly from seeing the malicious messages in their own chat\r\nclient.\r\nAlternatively, what happens in a situation where a disgruntled employee is let go and their account is terminated?\r\nCould they maintain some level of access and use it maliciously?\r\nOne key feature that some IM apps like Slack have is app integrations to allow bots and other functionality,\r\nusually using OAuth under the hood. This allows very useful functionality for users, but also opens up a whole\r\nnew angle for persistence and spoofing. In Slack’s case, its separation of user tokens and bot tokens allows for\r\nparticularly interesting spoofing and persistence capabilities, which we’ll come to later.\r\nWe could probably write several posts on OAuth apps alone. In fact, we’ve written about using OAuth for\r\npersistence more generally before. However, in this case we are going to focus on a couple examples of using a\r\nlegitimate Slack app maliciously. \r\nIn a previous blog post in this series, we spoke about shadow workflows using SaaS automation apps. We’re going\r\nto follow this theme again here and show how they can also be used with Slack. Previously, we used Zapier as our\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 2 of 13\n\nautomation app example, but this time we are going to use make.com. \r\nPersistent spoofing\r\nWe’ll show here how you can connect make.com to a Slack account you control and then maintain persistence,\r\nboth as that user and partial access even if the account is deactivated or deleted, by using bot tokens. This is\r\nespecially important in a disgruntled employee scenario as they could use this to maintain some level of access to\r\nSlack even if they were fired and had their account deleted. \r\nIf we create a make.com account and click to create a new scenario, we can select Slack from the long list of\r\nintegration possibilities. We’ll then be prompted to pick a specific Slack module. In more complicated scenarios,\r\nthese can be chained together to take actions on events, but in this case we are going to create a simple scenario\r\nwith just one module used to send a custom Slack message.\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 3 of 13\n\nCreating a new scenario in make.com and picking a Slack module\r\nIf we select the module “Create a Message” we’ll be prompted to select a Slack connection to use and then fill out\r\nthe other details for the module. Since we haven’t already created a Slack connection, we’ll be prompted to create\r\na new one. For this module, we have the option of creating either a user token or a bot token. \r\nA user token has full capabilities and will continue to operate in the event of a password change. However, if the\r\nuser account is deactivated or deleted then it will cease to work. In contrast, the bot connection is limited in\r\ncapabilities compared to a full user token, but the advantage is that it will continue to operate even if the user\r\naccount is deactivated or deleted.\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 4 of 13\n\nThis means gaining even temporary control of a Slack account, either through a user compromise or by being a\r\ndisgruntled employee (or fired employee), could enable the permanent ability to spoof messages unless the entire\r\napp is revoked from Slack. Even with the high bar set by shadow workflows, that’s a pretty epic level of\r\npersistence! So, we’re going to select the bot token for this example:\r\nPicking a Slack bot connection when making the Slack integration\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 5 of 13\n\nAccepting the OAuth2 permissions request for the app. Make.com still uses an app called\r\n“Integromat”, a legacy name for the company\r\nNow that we’ve finished setting up the bot connection, we can configure the specifics for the module itself. In this\r\ncase, we’ll demonstrate using it to send the same type of spoofed message we covered in the previous post, only\r\nit’ll be from a bot account. \r\nBy default, it’ll use the name and icon of the Slack app, in this case Integromat (Make.com’s former name).\r\nAlternatively, we can choose to override this, which we will do in this case to mirror the user spoofing attacks we\r\ncovered earlier. The only difference to a normal user message is there will be a small “APP” icon after the user. \r\nSetting the module to send a message to a public slack channel as the bot account\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 6 of 13\n\nConfiguring the bot to use a different name and photo in order to spoof the user\r\nThe phishing message sent once the scenario is run, which is almost identical in appearance to what\r\nwe saw previously except for “APP” after the name\r\nThe other great advantage with this is that it’s difficult to see which user is actually responsible for the spoofing. If\r\na compromised user account is used to send spoofed messages, not only may the real employee see the messages\r\nand alert security, but if the messages are investigated by a target or the security team, it’s quick to click on the\r\nuser and see the real email address associated with the account. \r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 7 of 13\n\nHowever, when it’s done with a bot token for an app, you can only see the Slack app that was responsible, not the\r\nactual user account it originated from:\r\nSending a spoofed message without the use of a bot token allows someone to click on the user and\r\nsee the original email address\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 8 of 13\n\nSending a spoofed message using a bot token from make.com takes the user to the Integromat app if\r\nthey click on the user, so they can’t easily see who was responsible\r\nAutomated phishing replies\r\nOk, so we’ve just seen how you can internally spoof a message via a Slack app in a way that’s harder to track back\r\nto the original compromised user account and also achieve persistence at the same time. Pretty neat! But can we\r\ndo more?\r\nOne of the great features of IM apps is the fact they are…well…instant! By making a slightly more sophisticated\r\nscenario with make.com, we can monitor public channels for messages that meet certain criteria and then\r\nimmediately spoof a target phishing link as a reply. Phishing where the target is the one to reach out originally is\r\nmuch more likely to be successful as it’s more like a watering hole attack - the phishing message itself won’t be\r\nseen as unsolicited.\r\nFor example, let’s consider a scenario where someone has forgotten their password, or some other common IT\r\nsupport request, and they raise a question on a Slack channel about it. We could monitor for that and automatically\r\nrespond. \r\nOne caveat here is make.com requires we use a user token for the message monitoring part and therefore this\r\nattack couldn’t survive a deactivated/deleted Slack user account. However, it will still survive password changes\r\nand so is still a useful persistence option too. Additionally, the bot token can still be used for the message sending\r\ncomponent in order to mask the source of the attack as above. \r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 9 of 13\n\nCreating a scenario to monitor public channel messages for certain keywords in order to reply with\r\nphishing messages\r\nIn this case, we have configured a Slack module to watch public channel messages using a user token and apply a\r\nfilter on those containing the words “password” and “reset”. If that is the case, we then trigger a spoofed threaded\r\nreply using the bot token and impersonating an “IT bot” and giving a link to documentation for how to perform a\r\nself-service password request. \r\nThis makes use of the same link preview spoofing techniques we covered in the previous post and the actual link\r\nwill present a fake Google login page to harvest credentials.  \r\nOur make.com scenario automatically responding in a thread with a targeted phishing link from a\r\nspoofed bot user, using a spoofed link preview\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 10 of 13\n\nHere’s a quick video demonstrating this combination of user spoofing, link preview spoofing and a shadow\r\nworkflow in action:\r\nTo summarize, heres a diagram to show how this all fits together:\r\nDiagram showing the connections between the attacker, compromised Slack account and make.com\r\nMulti-party spoofing\r\nAnother great possibility provided from using Slack apps and bot tokens for spoofing is the ability to spoof inline\r\nwith existing communications as multiple parties. Ordinarily, if a Slack user kept changing their name, handle and\r\nphoto for spoofing internally, Slack would change all existing messages to the latest profile data every time. That\r\nmakes it hard to spoof multiple identities in short time windows and so an attacker could only really spoof one\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 11 of 13\n\nperson at a time. However, with Slack apps you can inject messages as different people at different points of a\r\nconversation using bot tokens.\r\nConsider the following example, where I’m using my own internal account to message the CFO about paying a\r\nmalicious invoice that I have hypothetically raised. Perhaps they then indicate approval is needed from another\r\nparty, in this case the CEO. Similarly, this might be a common process for access requests requiring manager\r\napproval and many other business processes. \r\nIn this case, I’m able to quickly spoof a message as another user to act as the approval in a manner that is pretty\r\nsneaky. The only giveaway at first glance is the “APP” tag after the spoofed message.\r\nMulti-party spoofing of messages for advanced social engineering internally on Slack\r\nThis is just one example but the ability to spoof multiple identities simultaneously from just one compromised\r\naccount on what is usually seen as a trusted internal communications system really opens up a ton of possibilities\r\nfor social engineering attacks focused on lateral movement. \r\nSee more original research and technical content from Push\r\nImpact\r\nAfter two whole posts on attacking Slack, covering both external attacks during the initial access phase and\r\ninternal attacks in the persistence and lateral movement phases, we’ve covered a serious amount of ground! \r\nIt’s worth taking a step back and considering the key impact points:\r\nIM apps like Slack are now external phishing and social engineering vectors, not just internal ones\r\nUser spoofing can be used in novel ways to enhance social engineering that employees may not be familiar\r\nwith\r\nLink spoofing techniques can make phishing links much harder to spot and so increase social engineering\r\nsuccess\r\nMalicious Slack messages can be modified later to replace the phishing link to cover up the attack\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 12 of 13\n\nSlack apps, and especially bot tokens, can be used for very effective persistence techniques. Some\r\nexamples:\r\nIt’s possible to read all messages even after a compromised user changes their password\r\nIt’s possible to send (and spoof) messages even if the compromised user account is deleted (e.g. a\r\ndisgruntled employee who is fired)\r\nSlack apps and shadow workflows can be used to conduct some fairly advanced social engineering attacks\r\nonce an attack has a foothold on a Slack tenant. Some examples:\r\nAutomatically phishing employees in response to common IT support questions\r\nMulti-party spoofing for advanced social engineering\r\nConclusion\r\nIM apps have become the default internal communication for most organizations now, but are now a common\r\nmethod of communication with external parties, as well. This means they’ll become a key battleground in both the\r\ninitial access phase of compromises and the latter phases of lateral movement and persistence. \r\nThis also means organizations reliant on traditional email security gateways and email-based phishing training are\r\nlikely to see the effectiveness of these controls decrease if attacks shift to the IM apps. \r\nIn this article, we highlighted a number of spoofing, phishing and persistence techniques that can be employed by\r\nan attacker with a foothold that has compromised an internal account on a Slack tenant in order to persist their\r\naccess and perform lateral movement. In the previous article, we covered spoofing and phishing techniques that\r\ncould be used by external attackers in the initial access phase to get that first foothold in the first place.\r\nWhile this article focused on Slack specifically, similar attacks may be possible for other IM apps as well. Going\r\nforwards, it will be important for organizations to factor in these types of attacks into their security strategies.\r\nSource: https://pushsecurity.com/blog/phishing-slack-persistence/\r\nhttps://pushsecurity.com/blog/phishing-slack-persistence/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://pushsecurity.com/blog/phishing-slack-persistence/"
	],
	"report_names": [
		"phishing-slack-persistence"
	],
	"threat_actors": [],
	"ts_created_at": 1775434383,
	"ts_updated_at": 1775791319,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6a6d0ae3ec3254e704e58b937f5d82b6ca7a4b59.pdf",
		"text": "https://archive.orkl.eu/6a6d0ae3ec3254e704e58b937f5d82b6ca7a4b59.txt",
		"img": "https://archive.orkl.eu/6a6d0ae3ec3254e704e58b937f5d82b6ca7a4b59.jpg"
	}
}